perm filename SKLEIN.3[RLL,DBL]2 blob
sn#656175 filedate 1982-04-29 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00020 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 See all RLL.BBD[rdg,dbl],
C00004 00003 ∂TO SKLEIN@ISIB 13:25 8-Jan-82
C00010 00004 ∂11-Jan-82 1748 Steve Klein <SKLEIN at USC-ISIB> Re: Some comments
C00020 00005 ∂26-Jan-82 2013 Steve Klein <SKLEIN at USC-ISIB> awoof
C00021 00006 ∂08-Feb-82 1617 Steve Klein <SKLEIN at USC-ISIB> grmmph
C00022 00007 ∂TO sklein@isib 15:51 9-Feb-82
C00032 00008 ∂16-Feb-82 1415 Steve Klein <SKLEIN at USC-ISIB> postponement
C00033 00009 ∂TO skein@isib 18:01 17-Feb-82
C00034 00010 ∂TO SKLEIN@ISIB 16:47 1-Mar-82
C00038 00011 SNAFU
C00041 00012 ∂12-Mar-82 1530 Steve Klein <SKLEIN at USC-ISIB> NewKB problem
C00057 00013 ∂07-Apr-82 1546 Steve Klein <SKLEIN at USC-ISIB> onwards
C00060 00014 <Spoke with Steve ~2PM 15:18 8-Apr>
C00061 00015 ∂TO sklein@isib 12:31 12-Apr-82
C00070 00016 Spoke with Steve on 15-Apr-82 ::: 11:40AM
C00071 00017 ∂19-Apr-82 1645 Steve Klein <SKLEIN at USC-ISIB> zoom zoom...
C00078 00018 ∂20-Apr-82 1140 Steve Klein <SKLEIN at USC-ISIB> Re: Space, the final frontier...
C00087 00019 ∂TO sklein@isib 16:29 28-Apr
C00093 00020 ∂28-Apr-82 1931 <SKLEIN at USC-ISIB> minor think time
C00096 ENDMK
C⊗;
See all RLL.BBD[rdg,dbl],
also ARCHIVE.RLL[rdg,dbl] for backed-up information
(USERS.OLD had bunch of users,
SKLEIN.2 have old messages with Steve)
∂TO SKLEIN@ISIB 13:25 8-Jan-82
Some comments
Steve
(1) I realized this morning that the defn of *vaLue* is wrong.
The HighLevelDefn says to apply the MyLivesInSlot slot to the
value of (GetValue un 'MyLivesInUnit).
That's close: it should, however, apply the function stored on un:MyLivesInSlot
to that un:MyLivesInUnit value. As there is currently no direct mechanism for
doing that, we could define a function GetFromPointer,
which takes a unit, un, and returns (essentially)
(APPLY* (GetValue un 'MyLivesInSlot) (APPLY* (GetValue un 'MyLivesInUnit)))
The GetFromPointer unit would include some useful facts -- it rangetype should be
something like
(FSingleton (UnrestrictedType (*FromDomain GFP-Fn)))
where GFP-Fn would take a unit and return something like
'(*FromDomain *vaLue*Fn). [Or something like that -- see MapCross-Fn, or whatever.]
The idea is for *vaLue*:RangeType to be
(FSingleton (UnrestrictedType (*FromDomain *vaLue*Fn)))
where *vaLue*Fn takes a unit and returns the rangetype of the MyLivesInSlot of
that unit.
(2) Doug needs a brief, 1 page description of what's going on there - for some
report or other. It doesn't have to be prose, just enough for him to understand
what sort of things youse guys are doing, and why you are using RLL.
It might be interesting to see, in addition, your agenda of things needed,
and fixes made. (Basically for my edification...)
(3) Just a reminder: ComplexVV now calls (GetValue ? 'VerifyElement ...);
but should be calling a GetField - as the VerifyAll thing does.
(4) At some point I should send over the macro stuff I have up and running here;
and the next batch of LISP files. From there you could have the most updated
version.
(Until Rand and/or thesis stuff forces me back to hachery.)
(5) Some thoughts on EqualFormatSpec:
It would be a list, with each member of the form: (<format> <function>).
[That is, EqualFormatSpec:RangeType =
(FSet (FListN (UnitType (*P AnyFormat))
(FunctionType (*Range (FListN UnrestrictedType))))).]
If (fmt2 fn2) was included on fmt1:EqualFormatSpec, then
if some value, val, was acceptable to fmt2, then (fn2 val) will qualify as
an instance of fmt1. For example, FSet:EqualFormatSpec ==
( (FOrderedSet IDENTITY) ; Any ordered set is already a set
(FList MKSET) ; this removed duplicated elements
(FBag MKSET) ; (removes duplicated elements)
(FListN Scream) ; could be MKSET, but this is safer
(FSingleton LIST) ) ; ie this list qualifies*
*: actually the function FakeList should be used, where
(FakeList (v) (COND ((EQ v NoEntry) NoEntries) ((MustComputep v) v) (T (LIST v)))).
Given this, UnionDT and IntersectDT may be easier to (re)write, as well as
SubSpecFn for formats. Note it puts the facts (closer to) where they belong
-- on FSet, etc., rather than within a few functions.
Two final notes:
(i) Finding (fmt2 fn2) included on fmt1:EqualFormatSpec restricts the
fn1 in the (fmt1 fn1) included on fmt2:EqualFormatSpec. [Note it does not
completely define that fn1.]
(ii) Eventually it would be nice if EqualFormatSpec could be generated from
"first principles" -- looking on the various format's FormatCharacter.
----
That's all for now. Let me know how your work load dwindles, and whether/how
this RLL marrass(sp) works. I meandered over to ISIB last night, and found
the stuff we did unsaved! (or at least I couldn't find it).
Hope things are going ok,
Russ
∂11-Jan-82 1748 Steve Klein <SKLEIN at USC-ISIB> Re: Some comments
To: RDG at SU-AI
I'll look over the first 90% of your mss. later, but you are right on the last
point. I was on my way to the Consumer Electronics Show in Las Vegas just
after talking to you and managed to logout without saving the RLL image we
were working in. Good thing that the dribble file (presumably) still exists.
Murphy's law strikes again...
-------
∂13-Jan-82 1724 Steve Klein <SKLEIN at USC-ISIB> stufflets
To: RDG at SU-AI
Accumulation of small things:
∂TO sklein@isib 20:28 13-Jan-82
Possible answers
**** My comments are interspersed. enjoy...
1. for Range restrictions, the original solution you wrote up talks of
checking u:MyLivesInUnit 's SuperTypEx's for superspecs. However,
this only works for CLASS restrictions. If the RangeType spec is found
on a subunit for an INSTANCE, then it has no TypicalExampleOf slot and
hence no SuperTypEx's.
**** Q: Have you a scenario in which this occurs? As you noted, the only
place where a restriction currently makes sense is for classes --
basically because I didn't see any other place where a restriction
might occur...
HOWEVER, the concept seems still valid, since
it has some superior TypicalExamples. What do you think of changing
the defn of SuperTypEx (and rest of group) from
(Composition TypicalExample SuperClass TypicalExampleOf) to
(Composition TypicalExample SuperClass Isa) ?
**** Hmmm - Independent of the first point above, this might still
be a good idea. (Given that TypicalExampleOf is (essentially) a subslot
of Isa (I think). The question again is, is this needed? This will
make the computation of SuperTypEx (potentially) more expensive, if one
day we formally make Isa a complex slot. When will you want a SuperTypEx
of a non-typicalexample? (Beyond that possible case of restricting
from an instance.)
2. I'm tentatively calling the slot you named SuperSpecFn
FnForVerifyingRangeRestriction (unless you have an objection).
**** Sure - it's you who'll have to type that Moby-name.
But I think it does convey the correct idea.
3. Following convention, the fn on RangeTypeOfTypicalSubUnit:VerifyAll
seems to look like (LAMBDA (un sl val ...]. Is it the case that the
sl parm is ALWAYS RangeType for this fn?
**** Sorry - "sl parm"? Please explain.
4. Is the other parm for *vaLue*:ToCompute that you were speaking of
-COMPUTE or something else?
**** Yes (to the disjunct), it was something else: IGNORE-CACHE.
So the call should be something like
(PROG ((u (GetValue un 'MyLivesInUnit '(SAFESLOT)))
(s (GetValue un 'MyLivesInSlot '(SAFESLOT))))
(RETURN (GetValue u s `(SAFESLOT (-CACHE (,u ,s)) (IGNORE-CACHE (,u ,s))))))
[which, unless the "s" slot is exceptional, is about the same as
(UnitFnGV (GetValue un 'MyLivesInUnit '(SAFESLOT))
(GetValue un 'MyLivesInSlot '(SAFESLOT))
'(SAFESLOT)),
sorta]
The idea is to IGNORE the value stored in u:s -- that will be the
(*Do* FSeeUnit sOfu), which, if investigated, will lead to an infinite
recursion. Note we don't want to store this computed value on u:s -- instead
it will be up to *vaLue*:ToCacheValue to decide what to do with this.
Maybe this function could meander about, and caching the value only if
s:ToCacheValue said to do so. (ie something like
(LAMBDA (uN sL vAL ...) (* Note sL = *vaLue*, and uN is a subunit.)
(APPLY* (GetValue (GetValue uN 'MyLivesInSlot) 'ToCacheValue)
uN sL vAL ...))
5. If each of the FnForVerifyingRangeRestriction fns takes only a pair
of specs and the "loop" is done in RangeTypeOfTypicalSubUnit:VerifyAll,
things seem to look simpler. See anything wrong with this?
**** I think not - but perhaps I'm just confused. Could you spell out
your proposal. (It sound like you think you're going to keep hitting
RangeTypeOfTypicalSubUnit:VerifyAll, which is NOT the case.)
6. If I actually use the EqualFormatSpec approach instead of punting when
there isn't a match, exactly what should be done? The information
that is encapsulated in the transformation function doesn't help
in verifying that two specs are equivalent (at least to me). I wouldn't
necessarily think that you would want to actually do the transformation
and see what results as a way of telling whether it is legal...
Also not clear whether some mapping of the sub-specs needs to be done
DEPENDENT upon the particular mapping at this un-equal level...
Any enlightenment?
**** Depends on what you consider to be a legitimate subrange. I, for example,
feel queasy at the prospect of letting something of format FSingleton be a
restriction of a FSet format -- but you indicated this is acceptable.
Possibility one: only include fmt2 on fmt1:EqualFormatSpec if it is a legal
restriction -- this makes the task trivial -- just use ASSOC.
If you want to include other formats, then you may have to do something like
include another field - indicating its acceptability as a restriction;
or possibly here's a place when your could use the FormatCharacter slot directly,
(avoiding this EqualFormatSpec altogether): by indicating which of the
characteristics must be the same, or how different. Yes, 'twould be a bag of
worms, but might be worthwhile in the long run.
-------
Hi. Any additions to the following list of fns to be recorded when
called from LISPX level?
AddField AddValue
DeleteField
KillField KillValue
PutField PutValue
SubstField SubstValue
UA-PUT
**** Why this one? (/\)
UA-PUTPROP
[remember to twiddle EDITU to use this \fn.]
I think I'll assume all changes are written to a single file and a filter
predicate will be applied at load time to pick the ones to be executed.
**** Yes, this makes sense.
How will you address the case of when a function breaks?
Otherwise there is no (reasonable) way to keep the sequencing straight
between the calls that would appear on several files.
-------
**** Russ
∂13-Jan-82 1912 Steve Klein <SKLEIN at USC-ISIB> recording changes
To: RDG at SU-AI
∂26-Jan-82 2013 Steve Klein <SKLEIN at USC-ISIB> awoof
Hi. Typically, I got diverted onto other matters again. Got your
example (TypicalShip stuff) through almost to completion, so I suppose
that about 95% of the "task" is done...should be easy to then test our
first example (the time units). Several questions, of course, came up.
I should be back on track and have things "proved" near the end of the
week--get back to you then to go over the results, etc. Enjoy.
-------
∂08-Feb-82 1617 Steve Klein <SKLEIN at USC-ISIB> grmmph
The bug where accessing a unit causes an end of file error has reappeared.
Since this is extremely irritating, I'm going to see if I can pin down what
is happening. However, I need the CORLL sources to do so and can't find or
don't have access to them from RAND or SCORE...help.
-------
∂TO sklein@isib 15:51 9-Feb-82
A penny for...
Steve -
Finally got a chance to write down my thoughts - for what they're worth.
Working thru this example, the top call was
Goal 1:
GetValue(Ship#47 Cost),
(where Cost:Isa = AnyComplexSlot).
As no value was stored on the Cost slot of the Ship#47 unit, Cost:ToCompute
was called, which would compute this value.
Goal 2:
GetValue(Cost ToCompute)
had to be computed as well, which required ...
This ended up being inherited from TypicalComplexSlot:ToCompute, which,
if memory serves, basically calls
Goal 3:
GetField(Ship#47 Cost ToCompute).
Not finding a CostOfShip#47 subunit, this calls
GetValue(ToCompute ToComputeField),
handing it Ship#47 and Cost.
(Is this right? I don't think its ToComputeField(Cost)...)
Anyway, that TC:TCF function is an OR junction of a MapUntilOk and a
GetValue.
Note in this case, we'd like the MapUntilOk to return NIL, letting
the TC:TCF function return the value of
GetValue(Cost ToCompute) -- which is what should happen.
(That is, the result of Goal 3 is Cost:ToCompute.)
But back to the plot:
Let ops <= Ship#47:OrderedPrototypes. The MapUntilOk takes each op-i IN ops,
and asks for (GetField op-i 'Cost 'ToCompute '(-CreateSubUnit...)).
In our case, we'd like each such GetField to return an nonOK value,
permitting the overall MapUntilOk to return NIL.
If there is no op-i:Cost subunit, Cost:ToComputeField is called, which does
the correct thing -- with the -CreateSubUnit value in the "other" arg, this
will return NIL, as desired.
The problem is when there is such a subunit. The first such case is for
CostOfTypicalShip. Here GetField(TypicalShip Cost ToCompute) reduces to
GetValue(CostOfTypicalShip ToCompute).
This is appropriate -- if there was a value primitively stored, we'd want that
used. Otherwise there may be a HighLevelDefn associated with CostOfTypicalShip,
from which we could compute that ToCompute value.
In this case, there is no primitive CostOfTypicalShip:ToCompute, nor is there
a CostOfTypicalShip:HighLevelDefn. Now FunctionSpec:ToCompute (or maybe
the derived FunctionSpec:LispFn) tells us to check the
Orderedprototypes of the unit (here CostOfTypicalShip),
seaching for a default value.
CostOfTypicalShip:Orderedprototypes includes TypicalSubUnit, and then
some even more irrelevant units -- TyppcalAbstractThing and TypicalThing.
Currently none of the three units has a ToCompute slot -- note that ToCompute
isn't even defined for the latter two units.
Some notes: (1) The GetAccessFn included in FunctionSpec:ToCompute
insists that a value be found here -- it gives the warning message now found.
(I think -- I'm not quite sure of this.)
(2) Part of me wants to make AnySubUnit a subclass of AnySlot -- in which class
the TypicalSlot:ToCompute value will be found, saving the day. But the rest
of me conceeds that this would be a great step backwards... Sigh.
There are several things which could be done.
(i) Don't use GetAccessFn in FunctionSpec:ToCompute.
Use instead a related, but less complaining function -- one which tolerates
not finding a value. Then the caching part of this FS:TC will have to
be a bit smarter. (Given that this isN'T the suggestion I'm backing, I'll
not elaborate.)
(ii) Store some new constant on TypicalSubUnit:ToCompute, effectively meaning
stop looking, and return me. (Proposed name: NothingHereOrAbove.)
This value will be returned by MapUntilOk. Note we still want the OR
to ignore this answer, requiring a new predicate IsOk&Significant
(which is (LAMBDA (x) (AND (IsOk x) (NEQ x NothingHereOrAbove) x)).
This would go around the MapUntilOk.
Problems: should this value be cached on TypicalShip:ToCompute?
How should this be added to TypicalSubUnit -- given that it is not the function
which ToCompute:RangeType expects. Should FSingleton, and friends, know about
this new constant? Do we really need it? ... what a mess ...
(iii) Perhaps the value of CostOfTypicalShip:ToCompute should be something like
(*Do* FSeeU&S Cost ToCompute)? Working backwards, this may imply that
TypicalSubUnit:ToCompute be something like
(*Do* FExecute (LAMBDA (u s o) (* Here u is, eg, CostOfTypicalShip)
`(*Do* FSeeU&S , (GetValue u 'MyLivesInSlot) ToCompute))).
This seems hacky -- especially when the time comes to cache this value of
CostOfTypicalShip:ToCompute.
(iv) and now for the real proposal: Store something like
(*Do* FExecute (LAMBDA (u s o)
(GetValue (GetValue u 'MyLivesInSlot) 'ToCompute)))
This will compute, here, Cost:ToCompute. This value may then be cached away --
depending on the function associated with Cost:ToCacheValue (which will probably
be whatever is found on TypicalComplexSlot:ToCacheValue).
NOTE: this eliminates the need for that top OR in TC:TCF, at least in this
case.
I recommend leaving the OR in, for now at least, as other things may use
this TC:TCF function (ie if this is the function stored on TypicalSlot:TCF).
----
Finally, realize the same types of things must be done for
RangeType and DomainType as they're computed with ToCompute. (Ie this sort
of *DO* must be placed on those slots of TypicalSubUnit.)
----
Anyway, once this done, that Goal 3
[GetField(Ship#47 Cost ToCompute)] will return the correct value
[that is, the value of GetValue(Cost ToCompute)].
That will do the right thing -- satisfying Goal 2 and then Goal 1,
(i hope).
Sound good?
I'm not really happy about soln (iv) if it forces us to but something like
that messy *DO* clause on each slot on TypicalSubUnit. Perhaps we could
circumvent that problem by talking about a particular class of slots, which
"terminate" on TypicalSubUnit with this sort of value...
Perhaps we should use that variable approach to cache some special value
on each TypicalXXX:YYY, whenever TypicalXXX is on YYY:MakesSenseFor -- to
shorten the othrwise duplicated long search.
More later. Let me first mail this off, and await critiques. Then we
can pursue patches to other RLL problems, and then, finally, address some of
these even more time-consuming issues.
Russ
By the way, Ben says Hi.
∂16-Feb-82 1415 Steve Klein <SKLEIN at USC-ISIB> postponement
Hi. Things have gotten hectic again...mind if I delay a continuation of our
conversation for a couple of days?
Steve.
-------
No problem.
∂TO skein@isib 18:01 17-Feb-82
Quicky
Steve
I just realized I never had youse guys fill out a "non-disclosure
agreement" prior to using RLL.
So I'm now snail mailing a copy of that form, which I guess
you and Bill Mann should sign and send back. (who knows why?)
Russ
∂TO SKLEIN@ISIB 16:47 1-Mar-82
Re: MAPHASH problems in Interlisp??
Steve:
I just received this message -- I'm not quite sure why.
However, it might be relevant...
How are things going, anyway?
Russ
----
∂01-Mar-82 1554 Masinter at PARC-MAXC Re: MAPHASH problems in Interlisp??
In-reply-to: KINI's message of 23 Feb 1982 1604-PST
To: Vittal Kini <KINI at USC-ISIB>
cc: InterlispSites↑
(I'm cc:ing InterlispSites↑ on the response because this problem is not widely
known.)
Vittal:
(1) You have unfortunately run into one of the more subtle problems with
MAPHASH in Interlisp-10: if a garbage collection which MOVES STORAGE
occurs during the middle of a MAPHASH, it is possible for the hash
pointers to move around, and for entries to be missed and for some entries
to be visitied twice. This is the only situation in which MAPHASH will
omit items or present them twice (note that "rehashing" actually copies the
original array into another one, so that if a rehash occurs because of overflow,
you may get outdated information but not any duplicates.)
(2) The problem is that if a reclaim needs to increase the size of one of the
contiguous areas (such as array space or string pointer space), it may actually
move around pages of atoms. It isn't that atoms get compacted but rather that
other spaces have to increase which causes the atoms to get moved around.
(3) The way that I worked around this problem when I ran into it was
(a) MAPHASH down the array, collecting a list of the "keys"
(b) MAPC down that list, performing the operation
This guarantees that no string/array/pname garbage collection will occur during
MAPHASH.
There are some proposals for fixing this problem in Interlisp-10 (e.g., marking the
array that it is being maphashed, and if so marked, not rehashing during a
reclaim but fixing it the next puthash) but so far (for the last 4 years) no
progress on fixing it.
This bug is not present in other Interlisp implementations, as far as I know.
Larry
SNAFU
Steve -
SCORE went down just after you linked. I then tried to tell you
this, via SAIL, which was, you guessed it, down.
Anyway, what were you about to say?
Russ
∂TO sklein@isib 13:47 5-Mar
∂05-Mar-82 1341 Steve Klein <SKLEIN at USC-ISIB> Re: SNAFU
I was (and still am) in the process of gathering up the set of questions/
function changes outstanding, etc... Slightly sidetracked (again) on day-to-day
bug fixes, so what's your schedule rest of today? ...Ok to give you a call
about 5:00?
-------
[rdg] Unfortunately no -- I'm expecting a call about then, to finalize plans
about activities scheduled for this evening.
I have to run some errands about campus today -- probably consuming from
2-3. Calling anytime from 3 until 4:30 today is ok, as is anytime before
5:45PM on Saturday.
Sunday noon I'm leaving for a(n) HPP retreat, in Asilomar.
We'll return ca 5PM Tuesday.
∂05-Mar-82 1352 Steve Klein <SKLEIN at USC-ISIB> Re: ∂05-Mar-82 1341 Steve Klein <SKLEIN at USC-ISIB> Re: SNAFU
I'll aim for 3-3:30...
-------
∂05-Mar-82 1538 Steve Klein <SKLEIN at USC-ISIB> sigh...
Hi.
Looks like I won't get back to this part of the world again until Monday...
Probably best to further process the open questions and go over them
Wednesday after your're decompressed. Enjoy the intensity.
Steve.
-------
∂TO sklein@isib 15:41 5-Mar
psi...
Ok, will hear from you Wednesday.
Feel free to send some hints/overviews of your suggestions/modifications/...;
and thereby give me a chance to begin digesting them.
Or not, as you wish.
Enjoy
Russ
∂12-Mar-82 1530 Steve Klein <SKLEIN at USC-ISIB> NewKB problem
This is a recurrence of the problem I couldn't document before. If I make
a new KB, get into stack overflow. Analysis yields the loop of
GetValue(NumOpens Format) -->
GetValue(NumOpens RangeType) -->
GetValue(NumOpens FunctionSpec) -->
GetValue(NumOpens ToCompute
((-CACHE FunctionSpec)(From NumOpens FunctionSpec))) -->
GetValue(NumOpens Format) ...
Standard problem, except why coming up now, and due to the strange way of
problem occuring, the additional stuff on ToCompute gets lost, so the normal
halt doesn't happen... Familiar?
-------
Hmmm - yes, this is familiar, damnit. Let me look over your shoulder over at ISIB.
∂TO sklein@isib 13:42 13-Mar
A suggestion, or two
Steve -
Have you tried doing a GAINSPACE (or RECLAIM) when after a
stack overflow occurs? Perhaps that will free up the released stack
frames...
Also, I looked thru my various TODO files, or misc machines -- to
see if I ever recorded the fix to NumOpens, and whatever else. Alas,
I (too) hadn't. Sorry. Were you able to fix the problem?
(Damn these flakey systems anyway. If only my finger of accusation wasn't
directed back at me.)
Any other problems encountered (yes, that was rhetoric)?
Russ
∂15-Mar-82 1946 Steve Klein <SKLEIN at USC-ISIB> bug-debug
Here is my analysis of the bug caused by NumOpens not having a HLD or RangeType:
--> comes from TypicalPrimitiveSlot:ToCompute =
(*Do* FExecute (LAMBDA (un sl ot)
`(LAMBDA (unt oth)
,(EmptyValue un) ) ) )
*** Notice that the call to EmptyValue doesn't pass the Other info.
Since EmptyValue finally calls (GetValue un 'Format '(SAFESLOT)), if
the Primitive Slot that started this whole search was Format, we have
come full circle.
*** General Observation: Functions that contain embedded GetValue (or kin)
calls AND don't take other-type advice had better be extremely sure
that those calls can't be a source of trouble.
I'm not sure whether the viewpoint here should be that we should always be
able to find the format of a primitive slot, or that EmptyValue should take
Other-type stuff (here, easily passed down in TypicalPrimitiveSlot:ToCompute).
I await your clarifying missive...
-------
∂TO sklein@isib 12:00 16-Mar
Good sleuthing!
Yes, EmptyValue should take an additional arg, and merge that with SAFESLOT
on its call to GetValue. ...and yes, this is points to a general improvement to
the system -- essentially ALL calls to GetValue should have that additional
argument, passed to it from above.
Of course this makes things like EmptyVaue take longer in general. One solution
would involve MACROizing EmptyValue -- and when the additional argument is NIL,
not bothering with the AddOnChar function. This sort of trick might work in
general.
Final note: I checked the Dec/81 version of UTIL on Rand-Ai -- sure enough
EmptyValue was just changed to take that additional arg! So I'm consistent,
if forgetful
Suggestion: you might FTP over the versions of RLL.., UTIL.., etc from Rand-Ai,
and just see what sorts of things I'd twiddled way back when. Of course
all of these changes will be merged in after your changes have been added;
but who knows what other problems await which have already been (clandestinely)
solved...
Sorry about all of this tedious, meaningless overhead. Certainly it'll be
over soon. (By the way, I have this nice bridge I've been trying to sell
for a while...)
Russ
∂16-Mar-82 1224 Steve Klein <SKLEIN at USC-ISIB> Re: Good sleuthing!
I presume you also altered FormatIsList? to take the additional arg too. Since
this problem is (hopefully) solved by giving NumOpens a RangeType, I'll ignore
fixing the functions. Be interesting to see what other stuff is different, but
I think I'll wait for the next "release"...up to generating one when I ship back
my set of changes?
-------
--
∂TO sklein@isib 13:10 16-mar
Catches, drops and releases
Actually, I didn't correct "FormatIsList?" -- thanks for catching it.
Any others that you know about?
What will be involved with generating the next release? Simply merging a few
LISP code files? Will you have all the needed unit modifications in the
RecordKBChange file? and so you'll actually produce the desired new set
of units?
The only other change I know about is with the (X)UTIL files -- Dave's been
twiddling them to accomodate InterLisp-D on th Dolphin. I'll bring those
over to Rand-Ai eventually -- should I cart them to ISIB as well?
Is there anything else to do (besides wait for everything to collapse when
all of these modifications conflict with each other in the worst possible
ways...)?
Before I forget: had I mentioned my vacation plans? I'll be on the east coast
during 21-26 March, visiting NY and then Boston -- and hence, for the most part,
unavailable. Just thought I'd warn you ahead of time.
What plans have you?
Russ
∂16-Mar-82 1338 Steve Klein <SKLEIN at USC-ISIB> Re: Catches, drops and releases
I only mentioned FormatIsList? since it is the one that does the GetValue,
and hence really needs the advice, but wasn't passed it by EmptyValue.
My (current) notion of the next release cycle involves two operations.
One is merging of lisp code, both fixes and the recording stuff.
Second is merging of kb changes. Since you have made changes which aren't
recorded anywhere, presumably, the best thing to do is merge my changes into
your kbs. I'm willing to let you do that or to merge the changes myself
after grabbing the latest versions you have...presumably this latter move
would either require that you get back a set as the new base, or declare
the set here as the base (not clear there is any advantage to that).
I suppose where the most up-to-date stuff sits decides a lot of this.
Another interesting problem is how to record creation of new units. Offhand
suggestion involves calling the recording stuff directly from the functions
involved--NU, NewUnit, NewTypEx, etc... presumably a UA-PUT would end up
on the changes file... Any comments?
-------
---
∂TO sklein@isib 13:55 16-Mar
<blah>
Hmmm -- so how could I have gotten by fixing only EmptyValue?
...just one of those things I guess...
I'm neutral as to who actually plays watchdog durig the merging --
leaning towards letting you do it, purely thru laziness. Whoever does
it should clearly keep a full dribblefile of the goings-on, both for
posterity and for the other party.
I guess I'd like to let the official version sit of Rand-Ai -- that way
I can justify keeping my account there, and also I'll be able to use a different
version if and when I do any more hacking this lifetime.
Unit creation does indeed present a mess.
I think the only option is to "advise" the (top level calls to) NU, NewIsa, ...
[I almost suggested advising FNewUnit, which I think they all call,
(possibly excluding NU,) when I realized this wasn't quite right:
if that call is embedded, we do NOT wat it included, as the calling
function should be recorded, and that should be sufficient.
Note this means there should be a \NewKB...]
Its not quite clear what should happen here. Perhaps a UA-SETPROPLIST
should be recorded, corresponding to just before the call to EDITU.
The subsequent edits would be recorded appropriately.
Note the "additional value" to (\)PutValue
(telling it this is a new unit, to be handled accordingly)
is already done by EDITU.
Will this work; I've a gut level feeling I left out some important sub-case?
Russ
∂18-Mar-82 1716 Steve Klein <SKLEIN at USC-ISIB> NewZZZZZZZZ
To: RDG at SU-AI
Hi. Anuzer complication. Since NewIsa, NewSubClass, ... don't HAVE to
have all their inputs specified, they cannot be advised in the normal way
(to record their call). The most reasonable solution (pending your insight)
seems to be either give in and modify their definitions to call the /PutValue
type functions directly, or modify their definitions to do the recording call
after all the parameters have been specified. The unstated options are to
disallow calls with unspecified parameters or to record the calls "as-is" and
hence sometimes wrong. A nicer thing, of course, would be for lisp to
DIRECTLY support parameter defaults, parameter request/completion, and
advice coming either before or after the above were utilized. Dream on...
I don't feel that motivated (or stupid). I seem to recall that some other
dialects do this correctly...
Steve.
-------
∂TO sklein@isib 15:18 19-Mar
Oh yeah...
good point. Fortunately I think we can asssme that NewIsa and friends will
always be called from top level -- unless the user wants the interaction,
he is better off calling FNewUnit. So here's the suggestion:
Move NewIsa, NewSubClass, ... to \NewIsa, \NewSubClass, ...,
which will hence forth be the top level versions of the functions (using
the appropriate LISPXwhatever).
Then change NewIsa, NewSubClass ... to simply return an error message and die.
This will prevent anyone from calling NewIsa inside a function...
Realize this means every call to NewUnit should be recorded, and this,
in turn, leads to an easy fix:
Have NewUnit call \FNewUnit, which does all the right things -- ie records
all of its arguments.
There are still hassles when the user changes this neo-natal unit in the
EDITU call, but I addressed that in my last message. Did that
comment make sense?
I, too, feel there should be some better way of doing this... but couldn't
generate it.
Everything else there work? Anything else?
Russ
∂07-Apr-82 1546 Steve Klein <SKLEIN at USC-ISIB> onwards
Greets.
How was your vacation? Sorry I haven't dropped a note...been porting
all our (non-RLL) crud to Interlisp-VAX (due to our measly time-slice,
we need to off-load some of our computation somewhere...). Amazingly
enough it even works.
All the changes I've made have been complete as of the time you
(presumably) left. I suppose it's time to consolidate. I have a
feeling the changes you made (macros, etc.) are more likely to cause
problems than the changes I made...feel an urge to generate?
The files containing the changes from here are as follows:
RECORDKBCHANGE.. the stuff to implement recording (including changes to
edit functions and the like.
NEWADDITIONS.. functions I have added or fixed, suitably annotated to
indicate why.
PATCH.KB a fake KB containing new units to be distributed to
various previous KBs (made before the recording stuff
was extended to handle unit and KB creation)
KB-CHANGES.MAR16 an official file of changes, to be loaded by the
appropriate function from RECORDKBCHANGE.
Let me know what you think, what's new, etc., etc...
p.s. It turns out that the LISPX stuff uses "/" rather than "\" ...
-------
----
∂TO sklein@isib 16:26 7-Apr
Charge!!
Ok, I will look them over in the near future.
I don't imagine there'll be any non-trivial differences
-- that is, probably no alteration will require more than a few minutes.
What is the best strategy then?
Have you snarf over the Rand-Ai files, upgrade them at ISIB,
and then let me FTP them back to Rand-Ai at my leisure?
How hard do you think the upgrading will be?
Do you want me (logically) there during this process?
Russ
<Spoke with Steve ~2PM 15:18 8-Apr>
∂08-Apr-82 1438 Steve Klein <SKLEIN at USC-ISIB> a detail
Brief question: do you remember who calls RLL-CHANGE-FAULTS to make the
FAULTAPPLY and FAULTEVAL changes?
-------
∂TO sklein@isib 14:42 8-Apr
Hmmm
Something in UTILCOMS -- maybe START, or ...
Scan thru UTIL.. searching for RLL-CHANGE-FAULTS
(I would, if I could easily edit files once TNing from this terminal.)
Russ
∂TO sklein@isib 12:31 12-Apr-82
da answers, or whatever...
Steve -
(0: When I reread this letter today it sounded rather nasty and unfriendly.
I'm not quite sure why -- that was not my intend.)
Finally got a chance to look over the code, and agree with
essentially all of it. First some general comments:
(i) I CONSed up a new CORLL on <GREINER.CORLL>.
(Needed to en-XKB patch - see below)
The GAINSPACE thing may have screwed over CLISP -- feel free to remake CORLL
if that's the case.
(ii) The current LOGIN.CMD files tells Rand-Ai that, when in doubt,
GREINER is logging in on a Heath-19.
Unless you plan to use such a terminal,
you may want to twiddle the file accordingly.
(I'm assuming that, henceforth, you'll be on that account more often than I.
Hence, feel free to make whatever changes are needed to feel more at home.)
(iii) What do you know about <DONC>LOSTLISTS.TTY?
It sounds like it may be useful to find how uses how much, to figure what
should be optimized. (Or will this all be irrelevant when this all goes onto
DLisp?)
Onto some specific suggestions/revisions:
>>><<<
* RECORDKBCHANGE..
1) Good - I especially liked your fn cons-ing fn.
It took me a while to understand why you were passing 'arg.
While I now understand it, I wonder if there may be some simpler,
and less risky (with respect to passing shadow-able names) procedure --
based on some macro which LISTs the args - as in
(ARG-S arg 1 arg),
where the MACRO property of ARG-S expands that above form into
(PROG ((ans NIL) (count arg))
TOP
(COND ((EQP count 0) (RETURN ans))
(T (SETQ ans (CONS (ARG arg count) ans))
(GO TOP))))
(where 0 is (SUB1 1).)
This list would then be passed to the RecordKB.
(Note that these CONS cells would be generated anyway, in the KBChange function.)
2) Any ideas on how and where to store all of these \functions?
Perhaps on UTIL, as a seperate COMS entry?
Certainly all of those /xxx functions should be housed together,
but what of things which use them - like VerifySlots.
Unless you disagree, I suggest those additional functions become the default in
the RLL system -- ie they each replace their earlier versions in UTIL.
Hence the RLL system will automatically come with this spiffy
kb-change-recording mechanism.
Counterarguments?
3) There are other functions which call CreateSlot besides EDITU's descendants.
As such it shouldn't simply call /FNewUnit, as it now stands.
This opens a whole bag of worms -- what happens when you only sometimes
want to record a function's effects.
One possible solution would be to use a SPEC (or global?) variable,
which tells various functions whether or not to record this particular call.
(Note that each such function should then zero that variable).
Perhaps \FNewUnit and NU1 should be such functions, as each may or may not
want its call to be recorded.
Then things like EDITU, NU1, etc., can set that variable.
(If we follow this, then CreateUnit should call \FNewUnit,
knowing that this \FNewUnit invocation will be recorded only when it should be...)
...am I still forgetting some obvious case?...
[Or perhaps these functions should each have an additional argument,
to pass this effect?]
4) ConfirmSlot should NOT be doing the \UA-REMPROP
(in case we let someone else, like MyNewPossibleSlots:BeforePutValue use this fn).
Instead, let VerifySlots do the remproping as needed.
That is, move the (\UA-REMPROP ...) line from its location in
ConfirmSlot over to the (EQ ... 'IgnoreMe) clause in VerifySlots
(mutatis mutandis).
5) Some picky comments about LoadChanges:
(i) Check LoadedKBName (sp) -- I think it does the work of some of your code
there.
(ii) "New" should be a SPECVAR.
(iii) Why are you reading the file in all at once? What if it is huge?
Another case -- what if the user wants to step thru?
(iv) How can (CAR expr) be NIL? (in the bottom MAPC)
Are there other special cases of the COND (like *)?
6) The top level comment on NU1 can be shortened
-- it just does the work described in NU.
7) RecordKBChange:
(i) RecordingLevel and ChangesFileName should be declared GLOBAL.
(ii) Is USERNAME, the variable, reliable?
(iii) There is some function which does the PackFileName --
stored on same list, I assume, as LoadedKBName.
8) [VerifySlots should get the \UA-REMPROP -- see above.]
-----
* NEWADDITIONS..
1) Has DTVerifyRR been tested? I apparently don't quite understand it;
as I can't figure why the MAP2CAR is used. Does the embedded APPLY*
return an s-expression to be evaluated, or the result.
Finally, a useful addition to the comment in its definition would be an
"I live on unit : slot" type address.)
2) The destructive MAPCONCs in FigureMSF worry me. Have they always been there?
----
* PATCH.KB
This looks ok to me, but what do I know...
[I first XWRITEd it, to read it.
As a general comment, it may be safer to make transfer files (like this one)
as *.XKB files. Not only does this enhance readability,
but it also provides greater confidence when FTPing the file.
(As XKB is simple text, with no funny characters to foul out the transfer.)
A further consideration, (one which doesn't particularly apply here,)
is permanence -- someone will always be able to read in the XKB file,
but who knows how and when the HASHfilepackage will change...]
----
* KB-CHANGES.MAR16
Looks ok too. What is the fourth member of the list -- when will
it ever be non-1? Who uses it?
Russ
Spoke with Steve on 15-Apr-82 ::: 11:40AM
∂19-Apr-82 1645 Steve Klein <SKLEIN at USC-ISIB> zoom zoom...
To: RDG at SU-AI
Howzy. I can forsee on the near horizon a potential space problem at
Rand. The first question is whether the administrative people there
consider the RLL stuff to have any long-term usefulness, such that
any requests would be considered. Immediate questions concern whether
it would cause any problems if stuff on Rick's subdir was archived to
make more space (this, plus shipping dribble files and stuff back to ISI
would probably work for a while).
Any general comments or feelings?
∂TO sklein@isib 17:08 19-Apr-82
Space, the final frontier...
Steve -
Here's a copy of my communication with Keith.
If you like I'll ask him about giving me
(or perhaps a new <RLL> account) Rick's unused space.
How much space do you think you'll need in the short/long run?
Russ
----
∂14-Mar-82 1448 <CSD.GREINER at SU-SCORE> My space
To: wescourt at RAND-AI
cc: rdg at SU-AI
Keith -
I'm starting to feel guilty hording all sorts of space on the various
Rand machines. I attempted to ARchive all my Planner files on Rand-Unix --
but am not sure that I succeeded. As I never use that account, please feel
free to delete it; after all the relevant file have been archived.
As to Rand-Ai... I could certainly reduce my space utilization, if you
like. Let me know how tight space is there -- the time I'll spend condensing
my stuff will be proportional to that...
At some point we collectively will have to decide how/if I fit into
Rand's overall scheme. At that point RLL's official home can be fixed.
Until then I'll be quite happy simply leaving a running version there.
On other topics: how are things there? Anything coming of the
Planner Workbench? Which projects are you working on? and the rest of the
crew there? etc, etc, etc.
Russ
(Feel free not to make waves over this; I'm just trying to present the image
of being a concientious member of the computer community...)
-------
∂14-Mar-82 1444 Keith Wescourt Re: My space
To: CSD.GREINER at SU-SCORE
cc: rdg at SU-AI
Russ,
Good to hear from you. Send a msg to doris@rand-unix to ask about
whether your files on rand-unix have been archived. If they have,
delete them yourself and just leave your account inactive. Cleanup/archive
your 20 files as you see fit, but for right now I have no serious space crunch
here, though it's good to know where I can find pages if we need them.
If you have a working version of RLL here and have some online
documentation why don't you set things up so others can access them and
announce it via BBoard; that way I can always tell people you have an account
here to maintain RLL. Feel free to use the system along those lines if
that is convenient.
Things continue to change here. Gary Martins is out as program director
(he resigned) and rumor has it he will be leaving Rand after some time.
Tony Hearn is acting program manager. I am working on ROSIE and 20
support right now, and learning a lot by the former while doing some
interesting work on pattern matching techniques. I will make some
decisions soon about other research activities. I don't know what
exactly is happening on the Planner's Workbench-- I haven't touched
my work on it since the original hiatus when Rick left here. I have
heard than Ross Quinlan and Norm are working on something, but it
involves going back to writing a C implementation based on string
matching techniques. I am skeptical if that approach will yield
much fruit, if that is what thay are doing; in any case, my own
interest was on plan languages and "deep-structure" representations,
so I haven't even considered getting involved in their effort.
I feel bad that what we (especially you and I) were working on never
was completed. We were just getting to the point where we would have
had enough of a working system to discover and study some interesting
questions about plan databases. Other than my (our) personal
enlightenment, it seems to be down the drain now... sigh.
What's new with you. How's your thesis coming? Any ideas what you'll
be looking to do afterward?
Keith
-------
∂20-Apr-82 1140 Steve Klein <SKLEIN at USC-ISIB> Re: Space, the final frontier...
I guess the basic notion is that RAND-AI is an excellent computational
resource. Since we have a rather poor resource at the moment (3% of ISIB),
we are quite often limited in "production" by lack of cycles. Consequently,
there is probably a direct correlation between how much we will work in
RLL (and potentially enhance it) and the number of cycles we can snarf.
The kicker, though, is that very soon we are going to be progressing by
integrating RLL and the previous stuff we were doing (NIGEL). At that point
two things will happen: the amount of space needed will potentially go
up by about 4-6K pages over the basic RLL space (we do that stuff in an
8K page directory at the moment), and the "job" being done will go from one
of "pure" RLL to a mixture of RLL and otherwise funded stuff. There is a
basic question of whether Rand will see such work as advancing RLL to their
benefit while also clearly advancing our goals, or whether they will see
it as a blatant attempt to snarf their machine (or somewhere between...).
It is definitely not clear from your exchange with Keith Wescourt which way
they may think (or even how this should be presented...why isn't anything
ever easy).
-------
∂TO sklein@isib 14:48 22-Apr
Proposed message:
Steve -
I'm about to send this message to Keith Wescourt, unless you've
any corrections, comments, ...
(Perhaps later you/I/we should follow it up with a request for increase
Rand/ISI cooperation...)
-------
<<included text, later fixed and mailed to Keith>>
∂22-Apr-82 1338 Steve Klein <SKLEIN at USC-ISIB> ouch
Hi. Rand bit me a couple of days ago...kicked me off in the middle of
doing something (the net did, that is) and the job was gone before it
"allowed" me back. Is it possible to find out a direct dial-in number
so if this happens again I can just use a modem? Should I just ask
directly?
Happy thesising...
-------
∂22-Apr-82 1513 Steve Klein <SKLEIN at USC-ISIB> Re: Proposed message:
Seems correct, although the "real" project name is Penman (rather than Nigel,
which is a sub-part), with possible a parenthetical remark of "Multi-Paragraph
Text Generation". Since the message is generally a "status" announcement it
will be interesting to see whether you do or don't get an answer...
The notion of increased "cooperation" is definitely interesting, but I need
to check with my powers-that-be for when that is deemed auspicious... easy
enough for the moment, since it equates to a temporary no-op.
-------
∂TO wescourt@rand-ai 15:16 22-Apr
Up and Up
Keith -
Some people over at ISI have been using RLL as a tool for their Penman
project, attempting "Multi-Paragraph Text Generation", under William Mann.
While bringing up that integrated system, one of their aces (Steve Klein)
found and fixed a bunch of bugs in RLL, as well as made some sizable
improvements. (He and I have long been in close contact over these
issues.) Anyway, Rand-Ai's obsoleted version is now being replaced with
this new improved system; when everything is in place (and documented),
RLL will be available for general use.
Steve's been doing essentially all of the work -- using my Rand-Ai
account, of course. (Way back when I asked Rick if such loans were
alright, as was told to feel free to "share" my account with anyone who
was helping the cause.) Steve did say he would attempt to avoid using the
system, if ever it becomes loaded.
Any comments for him? I assume the new management has no objections to
this arrangement -- correct?
Russ
PS How are things going now? Will Rand's large turn-over rate continue?
To where has the Planner project's manpower been diverted? Anything new
and interesting there, in general, and with respect to your current work?
etc, etc, etc.
∂TO sklein@isib 21:43 22-Apr
Response
Here's Keith's response. (I mailed him a corrected version.)
Later we can ask for things like phone numbers, increased space, etc.
Did you ask those ptb (powers that be) about the possibility of buying
a slice of Rand-Ai for your work?
russ
-----
∂22-Apr-82 1645 Keith Wescourt Re: Up and Up
To: RDG at SU-AI
Reply-To: Wescourt at RAND-AI
Russ,
...I wondered what "you" were doing logged in from ISIB. Sure, it is
ok for Steve to use your account for RLL work as long as the results
are made available here; he should use discretion as to load av.
In fact, I am going to move your account into the "guest" timeslice
so there can be no question of impropriety.
Re turnover: only the Shadow knows.
Re Planner proj: Norm and Ross Quinlan are doing some work (in C)
on probabilistic truth maintenance engines-- more or less a
continuation of the thread Rick and I worked on with PENCIL and WAND
in ROSIE. I haven't really talked to them much about the work.
Bill Schwabe has found other activities in the Strategic Assessment Center
here.
Re me: I'm working on ROSIE development, both internals and user
packages, designing a subset of inter-process
communications and user interface capabilities that ROSIE can have
across implementations on the 20, VAX, and D0.
I'm also working on TATR, an ARPA project to implement a prototype
expert system for aiding Air Force personnel doing tactical air targeting.
That work is in ROSIE, and again I'm addressing the user-interface
requirements and design.
Keep in touch.
Keith
-------
∂TO sklein@isib 16:29 28-Apr
Recent Mail
Steve,
Feel free to read mail which comes to Greiner@Rand-Ai --
it may contain choice nuggets like:
∂28-Apr-82 1621 Keith Wescourt RAND-AI use
To: Greiner at RAND-AI, RDG at SU-AI
Russ & Steve,
I must request that you carefully monitor your use of RAND-AI during
the day, since some heavy usage has occurred recently during periods
of (for us) relatively heavy system load. I have been questioned
about this use by the department head and while I defended it, must
agree that it must maintain a low profile. While the account is in
the GUEST pie slice, the scheduler is not all that good in how it
handles windfall. My suggestion is that you not do any heavy
LISPing when the load averages in Classes 2 & 3 go above ~1.5
as obtained from the INFO MON command in the EXEC.
Thanks.
Keith
-------
∂TO wescourt@rand-ai, sklein@isib/cc 16:38 28-Apr
Peices of Pie
Keith -
Thanks for the defense. Both Steve and I assumed a
guest account status would keep this from happening.
(By the way, is any paticular time especially bad?)
Russ
∂28-Apr-82 1636 Russell Greiner <GREINER at RAND-AI> Re: RAND-AI Usage
To: Wescourt
cc: GREINER
Remailed-date: 28 Apr 1982 1633-PDT
Remailed-from: Russell Greiner <GREINER at RAND-AI>
Remailed-to: RDG at SU-AI
Keith--
I'm very sorry that you got flak for my usage. I had been giving only
cursory attention to the load averages and assuming that the class
scheduler would do a decent job. ...should have assumed that would never
be the case. There shouldn't be any more problems of this sort and
many thanks for letting us use the system. We'll keep you posted
about "releasable" versions.
Steve.
-------
∂28-Apr-82 1644 Steve Klein <SKLEIN at USC-ISIB> Re: Recent Mail
Mail like that somehow triggers an automatic awareness of whether it should
be read...or maybe it was the subject and the fact that I was the only one
using things... Hopefully the reply I sent has the correct flavor (as well
as content)... I assumed that since it was addressed to both of us, that
Keith wouldn't think that a reply directly from me was unusual.
-------
∂TO sklein@isib 16:46 28-Apr
Re: Re: Recent Mail
No problem. It sounded good. Carry on, McDuff. or whatever.
∂28-Apr-82 1656 Keith Wescourt Re: Peices of Pie
To: RDG at SU-AI
cc: sklein at USC-ISIB
Mail-from: ARPANET site SU-AI rcvd at 28-Apr-82 1640-PDT
Date: 28 Apr 1982 1637-PDT
From: Russell Greiner <RDG at SU-AI>
Subject: Peices of Pie
To: wescourt at RAND-AI
CC: sklein at USC-ISIB
Keith -
Thanks for the defense. Both Steve and I assumed a
guest account status would keep this from happening.
(By the way, is any paticular time especially bad?)
Russ
Russ,
I don't know if your job really was doing anything bad or not, but
people jump at any available target in these cases. It has not
been unusual to have 5 to 8 Interlisp-based jobs in the main scheduler classes
during mid-day recently, and I think the high(er) load avg is due to
competition there. Be that as it may, I think 10am to 3:30pm is the
peak use period, so if you can hold it down during that period, your
other use is likely to go unnoticed.
Keith
∂28-Apr-82 1931 <SKLEIN at USC-ISIB> minor think time
To: RDG at SU-AI
Hi. When you have a spare moment consider the following problem.
What should be on FExecute:FnForVerifyingAll?
Comes up in trying to do
TypicalSubUnit:ToCompute ← '(*Do* FExecute (LAMBDA (uN sL oT)
(GetValue (GetValue uN 'MyLivesInSlot) 'ToCompute)))
A sub-question of this is what is going on in ToCompute:VerifyAll with the
call "(GetValue 'xy 'DomainType)"?
I just shoveled the above form into TypicalSubUnit for the moment...
-------
∂TO sklein@isib 13:28 29-Apr
First thoughts
Steve,
FExecute's DomainType (which may or may not be used to compute the
FnForVerifingAll for these value format things) should be something like
(FListN (AtomType (EqVal *Do*) )
(AtomType (EqVal FExecute))
(FunctionType (*Domain (FListN UnitType
SlotType UnRestrictedType))))
Notes: I don't remember the real name for EqVal -- just delete those
(EqVal xxx) clauses if that's not correct.
Also, I'm also not sure whether those first two members of the FListN
are expected -- test it out, watching especially DefaultVerifyValue.
It might turn out things like FExecute doesn't use this
its DomainType to compute the FnForVerifyingAll -- in which case you'll
have to expand that by hand.
-----
∂Spoke with Steve from 1 to 3, 29-Apr